Commodity operating systems (OS) are used in amazingly diverse environments, from ubiquitous use in the home, to service in commercial, government, and military settings. These systems are tasked with handling all manner of sensitive data, from individual passwords and cryptokeys, to databases of social security numbers, to sensitive documents, and voice traffic.
The security of known commodity operating systems, however, is less than ideal. While some facets of their security will continue to improve, it is believed that competitive pressures to provide richer functionality and retain compatibility with existing applications will keep the complexity of such systems high and, therefore, their security assurance low.
Over the years, a variety of techniques has been used for executing multiple software modules within a computer system, thereby providing some amount of security. Early computer systems could execute multiple software programs, but they could only execute one program at a time. Such computers might load one program into memory and execute it to completion or other termination, before proceeding to a subsequent program that would then be loaded into memory and executed. As another example, various multitasking operating systems enable multiple programs (or selected portions thereof) to be loaded into memory at one time and executed in an alternating manner, according to a scheduling algorithm. Also, some processors include multithreading capabilities that enable multiple threads of one or more programs to be executed simultaneously on a single processor. Finally, multiprocessor computer systems have also become commonplace, in which each processor can execute one or more threads all at the same time.
Many computer systems generally attempt to isolate the code and data of each different software module from the code and data of any other software module within the computer system. As a result, one software module then cannot interfere with the execution of another software module by altering the latter's code or data. Such isolation may be provided for code and/or data that is stored on a hard drive (or other secondary data storage means) and/or that is resident in main memory (or other primary data storage means). The term “data” is generally used in a broad sense, to include data that is operated on by the instructions (code) of a software module as well as the contents of a stack and any other possible forms of data that are associated with a software module.
As one example of the isolation of code and data, many systems implement a virtual addressing mechanism, in which different software modules within the system have different virtual address spaces, with each virtual address space generally being mapped to different portions of the physical address space of the computer system, so that the virtual addresses of a given software module are generally only mapped to physical addresses that contain the code or data of that particular software module. Virtual addressing mechanisms are well understood by one of ordinary skill in the art. A given software module may attempt to access every memory location in its own virtual address space, accessing every memory location to which it has access, and it will still only be able to access its own code and data (assuming that there is no shared memory). Thus, providing a virtual addressing mechanism provides some isolation between the code and data of multiple software modules in a computer system and, therefore, provides some security.
Various other protection mechanisms may also be implemented in such computer systems to isolate the code and/or data of multiple software modules from one another.
The ×86 architecture provides two primary memory protection mechanisms that may be used by an OS (or other system software) to try to isolate the code and data of multiple tasks or processes that execute on the processor, namely, a segmentation mechanism and a paging mechanism. Windows and Linux use the paging mechanism, but they generally do not take advantage of the segmentation mechanism. Instead, these OSs define segments that include the entire addressable range of the processor, so that the segmentation protection mechanism becomes ineffective in providing isolation between the code and data of multiple tasks. Thus, for simplicity, this discussion focuses on the paging mechanism of the ×86 processor, which implements a virtual addressing mechanism. The invention, however, is not limited to implementations using the ×86 processor, or implementations using similar memory protection mechanisms.
Generally, for Windows and Linux, different user processes are generally given different virtual address spaces. The OS creates a different set of page tables (and a page directory) for each virtual address space, which maps the respective virtual addresses to physical addresses. Thus, the page tables for a given user process map that process's virtual addresses to the physical addresses that contain the code and data for that process. The page tables for the user processes also contain mappings for code and data of the OS, but the user processes cannot use these mappings because the user processes are executed at a Current Privilege Level (CPL) of 3 and these mappings are set to require a supervisor, i.e., a higher, privilege level (a CPL of 0, 1 or 2). Otherwise, the page tables for a given user process generally only contain mappings to physical memory pages that contain that process's code and data. Therefore, a user process can generally only access its own code and data. Executing the user processes at a CPL of 3 also prevents the processes from modifying their own page tables. Otherwise, a process could add entries to its page tables that map to any physical address in the system, so that the process could give itself access to the code and data of other software modules, including other user processes and the OS.
Windows and Linux generally provide adequate protection for the software modules in a computer system, so long as all of the software modules are well designed and well behaved, i.e., they are not attempting to circumvent the protection mechanism. Thus, many processes may be running concurrently in such a computer system, with the OS giving each process a share of the system resources, including processor time, memory space and hard disk space, without any of the processes interfering with the code or data of the other processes.
As shown in FIG. 1, a simple computer system 2A has multiple software modules. The computer system 2A includes system hardware 100A, an OS 20A, a first application 40A and a second application 40B. The system hardware 100A may be conventional hardware based on, for example, the ×86 platform, and the OS 20A may be, for example, Windows or Linux. The applications 40A and 40B may be any applications designed to run on the system hardware 100A and the OS 20A. The OS 20A also includes a set of drivers 29A, which may be conventional drivers for the OS 20A, possibly including one or more drivers from a company that is different from the OS vendor (a third party vendor).
The OS 20A, in conjunction with the system hardware 100A, attempts to isolate the code and data of the applications 40A and 40B from one another. For example, the OS 20A and the system hardware 100A may implement a virtual addressing mechanism, as described above. As illustrated in FIG. 1, implementing such a protection mechanism may be characterized as establishing an isolation barrier 80B between the applications 40A and 40B, preventing (or at least hindering) one application from accessing the code and data of the other application. There may also be some code and/or data that is shared explicitly or transparently between the applications 40A and 40B. Techniques are known for allowing such sharing of code and data, while maintaining isolation between the applications 40A and 40B. For example, the OS 20A may mark physical memory pages that contain shared code or data as read only, such as when using a copy-on-write (COW) technique.
The isolation barrier 80B may be referred to as an “OS isolation barrier” because it is implemented by the OS 20A, in conjunction with the system hardware 100A. The OS 20A, again in conjunction with the system hardware 100A, also establishes an OS isolation barrier 80A between the OS 20A and all applications in the system, including the applications 40A and 40B, so that the applications are prevented (or hindered) from directly accessing the code and data of the OS 20A. In the case of a Windows or Linux OS running on an ×86 platform, as above, the OS isolation barrier 80A is established by executing the applications in the system at a CPL of 3 and requiring a supervisor privilege level to access memory pages containing the code and data of the OS 20A.
Although the Windows and Linux OSs provide adequate isolation between software modules for computer systems that contain only well designed and well behaved software modules, malicious software modules have been known to wreak havoc in such computer systems by circumventing these protection mechanisms. In particular, such malicious software modules have been known to breach the OS isolation barriers 80B and 80A, and corrupt the code and/or data of other applications in the system, and/or of the OS itself. Numerous security vulnerabilities have been discovered in the Windows OSs and in the Linux distributions, and many of these vulnerabilities have been exploited by hackers using different types of malicious software, such as viruses, worms, etc. Poorly designed or implemented software as well as misconfigured, though well-written, software may inadvertently bypass these protection mechanisms too and may, unintentionally, wreak havoc in a computer system. While the present description generally relates to protecting against malicious software, it also applies to protecting against software that inadvertently has the same or similar effects as intentionally malicious software.
As is too well-known, hackers exploit the vulnerabilities of today's systems for a variety of reasons and with a variety of goals, some being relatively benign and others being quite destructive or disruptive. As one example, a malicious software module may be written and deployed that searches for sensitive data on a computer's hard drive or in its memory and transmits any such sensitive data back to the hacker that launched the malicious code.
Security threats and data breaches have been gaining greater notoriety, and it is widely accepted that something should be done to improve the security of the ubiquitous personal computer. In particular, there is a recognized need to improve the security for the vast number of computers based on the ×86 architecture. Many believe that software changes alone will not provide adequate protection. Accordingly, many different companies are working toward solutions that involve substantial changes to both the system hardware and the system software, i.e., the operating system, of a computer system. Many such security measures, however, require substantial changes to application level software as well.
With respect to the ubiquitous ×86 platform, much of the work being done in this area requires substantial hardware changes or an entirely new hardware platform. This work would also require substantial changes to existing software platforms, including system software and possibly application software. Applications in some of these implementations might also have limited access to input/output devices because of a limited supply of trusted device drivers.
The amount of money that is invested in computer hardware and software based on the ×86 architecture throughout the world is enormous. Many individuals, businesses, schools, governments and other organizations will be reluctant to scrap their current ×86 systems, along with all the software that currently runs on ×86 systems, and replace them with new technology. Even if a new, more secure and widely accepted hardware platform were available today, it would still take a long time for the new hardware to become anywhere near as widespread as the ×86 platform is today. In the meantime, a large number and proportion of computers would remain vulnerable to the security threats described above.
Notwithstanding the foregoing, there are some proposed security measures that may be implemented primarily in software. In particular, there are some such measures that use virtualization technology to create multiple virtual machines (VMs), where different software modules run in different VMs. It is widely recognized that a well-designed and implemented virtualization layer can generally provide much greater isolation between multiple VMs than a general OS can provide between multiple software modules.
A general computer system 2B, referring now to FIG. 2, is described in co-pending application Ser. No. 11/584,178, filed 20 Oct. 2006, titled “Isolating Data within a Computer System Using Private Shadow Mappings,” herein incorporated by reference in its entirety for all purposes, in which multiple VMs are implemented to isolate multiple software modules from one another. The computer system 2B includes system hardware 100B, which may be conventional hardware, such as hardware based on the ×86 platform. The system hardware 100B may be substantially the same as the system hardware 100A of FIG. 1, or it may be substantially different. Virtualization software 200A executes on the system hardware 100B and supports a plurality of VMs, such as a first VM 300A and a second VM 300B, in a known manner. Virtualization software 200A may comprise a virtual machine monitor (VMM) for example, such as a VMM as implemented in a virtualization product of VMware, Inc. of Palo Alto, Calif. Such a VMM and other possible units of the virtualization software 200A are described in greater detail below.
In supporting the VM 300A, the virtualization software 200A virtualizes a virtual system hardware 310A, which may be based on an existing hardware platform, such as the ×86 platform. An OS 20B, along with a set of drivers 29B, runs on the virtual system hardware 310A. The OS 20B may be any OS designed to run on the hardware platform virtualized in the virtual hardware 310A. For example, if the virtual hardware 310A is based on the ×86 platform, the OS 20B may be, for example, a Windows OS, Solaris OS, Mac OS X, Novell Netware, or a Linux OS. The set of drivers 29B may be conventional drivers for the OS 20B. A first application 40H and a second application 40D run on the OS 20B. The applications 40H and 40D may be any applications designed to run on the platform of the virtual hardware 310A and the OS 20B.
Similar to the OS 20A of FIG. 1, the OS 20B, in conjunction with the virtual system hardware 310A, attempts to isolate the code and data of the applications 40H and 40D from one another, establishing an OS isolation barrier 80B between the applications 40H and 40D. Also similar to the OS 20A of FIG. 1, the OS 20B, again in conjunction with the virtual system hardware 310A, also establishes an OS isolation barrier 80A between the OS 20B and all applications in the VM 300A, including the applications 40H and 40D. Thus, the VM 300A may be substantially the same as the computer system 2A, except that the virtual system hardware 310A is virtual hardware, virtualized by the virtualization software 200A, instead of physical hardware.
In supporting the VM 300B, the virtualization software 200A virtualizes a virtual system hardware 310B in a like manner as done for the VM 300A.
The virtualization software 200A isolates the VMs in the computer system 2B from one another. For example, the virtualization software 200A allows software within the VM 300A to access portions of physical memory in the system hardware 100B and it allows software within the VM 300B to access other portions of the physical memory. The virtualization software 200A maps attempted memory accesses from the respective VMs 300A and 300B to different portions of the physical memory, ensuring that no memory address generated by software in one VM can access code or data of another VM. In a similar manner, the virtualization software 200A maps attempted hard disk accesses from the respective VMs 300A and 300B to different portions of one or more hard disks in the system hardware 100B, ensuring that one VM cannot access the hard disk space of another VM.
The virtualization software 200A also takes other precautions to isolate the VMs in the computer system 2B from one another, and from the virtualization software 200A, itself. For example, U.S. Pat. No. 7,281,102 to Agesen et al., “Restricting Memory Access to Protect Data when Sharing a Common Address Space”, (“the '102 patent”), describes methods that may be used to enable a VMM to occupy a portion of a linear address space of a VM, while preventing the VM from accessing the memory of the VMM. There are also various other methods that enable virtualization software to coexist with VMs in a virtual computer system, while protecting or isolating the virtualization software from software within the VMs. The virtualization software 200A may prevent software within the VMs 300A and 300B from directly accessing a Direct Memory Access (DMA) device to prevent the possibility that the DMA device could be used to access either the hard disk space or the memory of other VMs or of the virtualization software itself.
Thus, the virtualization software 200A, in conjunction with the system hardware 100B, may be said to establish a first isolation barrier 280B between the VMs 300A and 300B and a second isolation barrier 280A between the virtualization software 200A and all VMs in the computer system 2B, including the VMs 300A and 300B. The isolation barriers 280A and 280B may be referred to as “virtualization barriers” because they are implemented by the virtualization software 200A, in conjunction with the system hardware 100B. The isolation barriers 280A and 280B may also be referred to as virtualization barriers because they are established through the virtualization of hardware resources, such as the virtualization of system memory.
Virtualization techniques may provide better security and more effective isolation between multiple software modules than a general OS may provide. Thus, the virtualization barriers 280A and 280B of FIG. 2 can generally provide much better isolation between the multiple VMs 300A and 300B and the virtualization software 200A than the OS isolation barriers 80A and 80B of FIG. 1 provide between the multiple applications 40A and 40B and the OS 20A. Although computer systems that establish multiple VMs and that run different software modules within the different VMs generally provide better isolation for the software modules than do general OSs, such virtual computer systems have other limitations.
As an example of one limitation, if the software within a VM becomes corrupted by malicious software, the same problems described above relative to non-virtualized computer systems can occur within the affected VM. The software modules within the particular VM may be compromised by the malicious software. Approaches to retrofitting operating systems to possess higher-assurance security execution environments using multiple virtual machines, new operating systems, secure co-processors, or substantial changes to the processor architecture have been explored. Unfortunately, these may demand not insignificant changes in how applications are written and used, and how OS resources are managed. Such departures from standard operation pose a substantial barrier to adoption of these known approaches.